Practical EMV Relay Protection

Andreea-Ina Radu, Tom Chothia, Christopher J.P. Newton, Ioana Boureanu and Liqun Chen

This work will be published at the 2022 IEEE Symposium on Security and Privacy

Download paper

Findings

Summary

Demo Video

This video explaining all the pieces of equipment involved in the attack and how they interact. The video contains an edit that protects personal banking information.

Details

Contactless Europay, Mastercard, and Visa (EMV) payments are a fast and easy way to make payments and are increasingly becoming a standard way to pay. However, if payments can be made with no user input, this increases the attack surface for adversaries and especially for relay attackers, who can ferry messages between cards and readers without the owner’s knowledge, enabling fraudulent payments. Payments via smart-phone apps generally have to be confirmed by a user via a fingerprint, PIN code, or Face ID. This makes relay attacks less of a threat.

However, Apple Pay introduced the “Express Transit/Travel” feature (May 2019) that allows Apple Pay to be used at a transport-ticketing barrier station without unlocking the phone, for usability purposes. We show that this feature can be leveraged to bypass the Apple Pay lock screen, and illicitly pay from a locked iPhone, using a Visa card, to any EMV reader, for any amount, without user authorisation.

Furthermore, Visa has proposed a protocol to stop such relay attacks for cards. We show that Visa’s proposed relay-countermeasure can be bypassed using a pair of NFC-enabled Android smart phones, of which one is rooted.

We propose a new relay-resistance protocol, L1RP, based on our findings that EMV distance bounding can be done more reliability at Level 1 (ISO 14443-A), than Level 3 (EMV application). We formally verify our L1RP protocol, and prove it secure using Tamarin.

Apple Pay Transport Mode Attack Explained

The attack against Apple Pay Transport mode is an active Man-in-the-Middle replay and relay attack. It requires an iPhone to have a Visa card (credit or debit) setup as “transport card”.

If a non-standard sequence of bytes (Magic Bytes) preceeds the standard ISO 14443-A WakeUp command, Apple Pay will consider this a transaction with a transport EMV reader.

We use a Proxmark (this will act as a reader emulator) to communicate with the victim’s iPhone and an NFC-enabled Android phone (which acts as a card emulator) to communicate with a payment terminal. The Proxmark and card emulator need to communicate with each other. In our experiements, we connected the Proxmark to a laptop, to which it communicated via USB; the laptop then relayed messages to the card emulator via WiFi. The Proxmark can also directly communicate with an Android phone via Bluetooth. The Android phone does not require rooting.

The attack requires close proximity to the victim’s iPhone. This can be achieved by holding the terminal emulator near the iPhone, while its rightful owner is still in posession, by stealing it or by finding a lost phone.

The attack works by first replaying the Magic Bytes to the iPhone, such that it believes the transaction is happening with a transport EMV reader. Secondly, while relaying the EMV messages, the Terminal Transaction Qualifiers (TTQ), sent by the EMV terminal, need to be modified such that the bits (flags) for Offline Data Authentication (ODA) for Online Authorizations supported and EMV mode supported are set. Offline data authentication for online transactions is a feature used in special-purpose readers, such as transit system entry gates, where EMV readers may have intermittent connectivity and online processing of a transaction cannot always take place. These modifications are sufficient to allow relaying a transaction to a non-transport EMV reader, if the transaction is under the contactless limit.

In order to relay transactions over the contactless limit, the Card Transaction Qualifiers (CTQ), sent by the iPhone, need to be modified such that the bit (flag) for Consumer Device Cardholder Verification Method is set. This tricks the EMV reader into believing that on-device user authentication has been performed (e.g. by fingerprint). The CTQ value appears in two messages sent by the iPhone and must be changed in both occurances.

A video of the relay in action taking £1000 from a locked iPhone:

Responsible Disclosure

The details of this vulnerability have been disclosed to Apple (Oct 2020) and to Visa (May 2021). Both parties acknowledge the seriousness of the vulnerability, but have not come to an agreement on which party should implement a fix.

What Can a User Do to Protect Themselves?

While either Visa or Apple implement a fix for the problem, we recommend users to not use Visa as a transport card in Apple Pay. If your iPhone is lost or stolen, activate the Lost Mode on your iPhone, and call your bank to block your card.

Visa-L1 Attack Explained

Our second attack (unrelated to Apple Pay) is against Visa’s proposed protection against relay attacks, which we dubbed the Visa-L1 protocol. This attack is independed of our Apple Pay work. Visa-L1 relies on the inability of the attacker to change the UID of a card or mobile phone and the difficulty of relaying the ISO 14443 messages, due to their timing constraints. However, setting a desired UID on some mobile devices is possible, if the device is rooted.

Briefly, in Visa-L1, the UID the card sends to the EMV reader, at ISO 14443 level, is then resent, encrypted, as part of the EMV protocol. The EMV reader will decrypt it, and check if it matches the initial UID.

An attack can be carried out with a pair of NFC-enabled Android phones, one of which needs to be rooted (the phone acting as the card emulator). The reader emulator reads the UID of the Visa-L1 card and sends this to the card emulator, which sets it as the device’s UID. A straightforward relay of EMV messages is then carried out.

The attack is possible because the protocol’s security relies on a random value send only from the card side, which we can manipulate, and there is no randomness from the EMV reader.

Responsible Disclosure

The details of this vulnerability have been discussed with Visa. The protocol is meant to protect against attackers using unmodified devices, and Visa believe that rooting an Android smartphone is a difficult process, which requires high technical expertise.

What Can a User Do to Protect Themselves?

The Visa-L1 protocol is, to the best of our knowledge, not yet implemented in commercial cards, therefore users should not be affected.

Contacts

Acknowledgements

This work is part of the “TimeTrust” project, funded the UK’s National Cyber Security Centre (NCSC). We thank Mastercard UK and Visa Research for providing useful insights and feedback.